前面我們已經用過 Cloud Storage、BigQuery，也實際建立過 Cloud SQL。做到這裡，開始有一個更根本的疑問：
既然它們都能存資料，為什麼還需要這麼多不同服務？

一開始很容易把問題簡化成「SQL 還是 NoSQL」。但真的比較 Bigtable、Cloud SQL 之後，我才發現這種問法太粗糙。
真正該問的是：
這批資料會怎麼被寫入？怎麼被讀取？需要多快？需要多大規模？又願意為這些能力付多少成本？

1. 把「資料長相」和「使用方式」分開看

一開始很容易用資料格式來判斷服務：
表格資料就 SQL，JSON 就 NoSQL。
但這其實不夠。

同樣是結構化資料，如果是訂單交易，重點可能是即時寫入、交易一致性；如果是歷史分析，重點則是一次處理大量資料。另一方面，NoSQL 也不是「欄位比較自由」這麼簡單，它通常是在規模、延遲與資料模型之間做取捨。原本整理的內容也把 Cloud SQL、BigQuery、Bigtable、Firestore 放在不同工作負載下，而不是互相取代。

所以我現在不先問：
SQL 還是 NoSQL？

而是先問：
這個系統最重要的讀寫模式是什麼？

這個問題後面會一路影響 Schema、Key、效能和成本。

2. Bigtable 讓我真正理解「Schema 是為查詢而設計」

以前設計資料表，習慣會先想：

• 有哪些欄位？
• 欄位型別是什麼？
• 要不要拆表？

但 Google Cloud 對 Bigtable 的建議完全不同。
官方現在明確強調：
Design your schema for the queries that you plan to use.

也就是先想「未來怎麼讀」，再決定 Row Key、Column Family 與整體資料組織。
這讓我改變了一個習慣。
以前是：
先設計資料，再想怎麼查。

現在更像：
先列出最重要的查詢，再反推資料怎麼放。

例如 IoT 資料，如果最常查的是「某一台設備一個月的資料」，Row Key 的設計就應該讓同一設備的時間序列容易被連續讀取，而不是單純把時間放在最前面。

這不是語法問題，而是存取模式直接塑造資料結構。

3. Row Key 看起來合理，不代表真的合理

Bigtable 最容易讓我低估的地方，就是 Row Key。
一開始我會覺得日期很好用：
資料本來就有時間，那就用日期當 Key。

但 Google Cloud 官方特別提醒，Row Key 如果設計成可預測、集中式的順序，很容易讓寫入落到相近範圍，最後形成 Hotspot。官方也建議把寫入盡量平均分散到不同節點。
這和我前一天碰到 BigQuery Partition 很像，但目的完全不同。

BigQuery 的 Partition 主要是：
少掃資料。

Bigtable 的 Row Key / 資料分布則是：
避免大量流量擠在同一小塊資料區域。

這個差異讓我意識到，同樣都叫「分區」，背後要解決的問題可能完全不同。

4. 真正成熟的 Schema，不是設計一次就結束

這是我從 Google Cloud 官方文件裡看到最值得延伸的一點。
Bigtable 的官方設計流程不是：
想好 Schema → 上線。

而是：
Gather → Design → Test → Refine

官方甚至建議用實際工作負載做壓力測試，再搭配 Key Visualizer 和 Cloud Monitoring 檢查 Hotspot、CPU 使用與延遲，然後再修改 Schema。

這讓我重新理解「Schema Design」。
它不是一次性的資料結構設計，而比較像效能假設：
我猜這種 Row Key 會合理，
接著用真實讀寫模式驗證，
不合理就改。

也就是說：
資料庫設計本身也是一個需要驗證的假設。

這個觀念我覺得比單純背 Bigtable 的功能更重要。

5. Bigtable 強的地方，反過來也告訴我它不適合什麼

Google Cloud 把 Bigtable定位在低延遲、高吞吐量、可擴展到 billions of rows 與 TB／PB 級資料的場景。它特別適合 time-series、IoT、監控指標、大量單鍵資料等工作負載。
但官方同時也說得很清楚：
Bigtable 不是傳統關聯式資料庫，不支援一般關聯式 JOIN，Transaction 也只支援單一 Row 範圍。
這反而讓選型變得更容易。

如果我的核心需求是：

• 複雜關聯
• 多表 JOIN
• 明確 Transaction
• 傳統 MySQL / PostgreSQL 生態

那麼 Bigtable 的超大規模能力可能根本不是我要的。
所以現在我看服務，不只問：
它有什麼能力？

我還會問：
為了得到這些能力，我放棄了什麼？

6. 取捨：可用性每提高一級，都有代價

實際建立 Cloud SQL 時，我很快發現它和 BigQuery 的使用感完全不同。

BigQuery 幾乎不用先決定機器規格；Cloud SQL 則一開始就要面對 Edition (產品等級)、CPU、Memory、Storage、HA (High Availability，高可用性) 等選項，而且每個選項都會反映到成本。

Google Cloud 目前的 Cloud SQL for MySQL 有 Enterprise 與 Enterprise Plus。兩者不是單純「高階版／低階版」，而是在效能、可用性、Observability、Data Protection 上提供不同能力。Enterprise Plus 例如提供更高 SLA、較低的維護停機時間、進階 DR 與更多效能功能。

這讓我現在不會只看：
哪個比較強？

而會改問：
這個系統真的需要這個等級的可用性嗎？

因為高可用、更多 CPU、更多記憶體都不是免費附送。

7. 資料庫選型，其實是在買一種「負載處理方式」

Cloud SQL 的費用由 CPU、Memory、Storage、Network 等項目構成，不同 Edition 與高可用配置也會影響價格。
Bigtable 則走另一種方向：透過 Cluster / Node、Autoscaling 與大規模分散式架構來處理高吞吐讀寫。

所以我現在不會再把資料庫選型理解成產品比較表。

真正的差異是：
我想讓系統用什麼方式承受我的工作負載？

如果需要的是交易一致性與關聯操作，Cloud SQL 可能更自然。

如果需要的是極大量、低延遲、單鍵存取，Bigtable 才開始有優勢。

而且選型時還要把成本一起放進去看。原本實際操作也讓我注意到，不同服務的「最低計費單位」差很多；這也是為什麼不是所有能開的服務都值得開。

到最後，我認為真正值得留下來的不是：
Cloud SQL 適合什麼？
Bigtable 適合什麼？

而是這四個問題：

1. 資料會怎麼被讀寫？
2. 最重要的查詢模式是什麼？
3. 我要的是 Transaction、Latency，還是 Scale？
4. 為這些能力，我願意承擔多少成本與複雜度？

當這四個問題回答清楚之後，SQL / NoSQL 往往就不再是一個難選的二選一題。

參考資料

1. Google Cloud — Bigtable overview
2. Google Cloud — Schema design best practices
3. Google Cloud — Design a schema
4. Google Cloud — Cloud SQL pricing
5. Google Cloud — Choose a Cloud SQL edition